Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redefine blocksizes #399

Merged
merged 12 commits into from
May 14, 2024
Merged

Conversation

mtfishman
Copy link
Collaborator

@mtfishman mtfishman commented May 8, 2024

This is a first pass at #369, as discussed in #255.

To-do:

  • Full test coverage.
  • Add documentation.

Some questions to discuss:

  • Should BlockSizes be a subtype of AbstractArray? In the latest, I didn't go that route and instead implemented the iterator interface. My reasoning was that it is not obvious what eltype should be for arbitrary block arrays, and even within block arrays the types of the sizes of different blocks could be different. EDIT: In the latest, BlockSizes <: AbstractArray with a concrete element type based on eltype.(axes(array)).
  • The current design computes the block size of a block using the size of the view of that block. Is that a good definition, or is it better to get the block sizes from the axes? EDIT: Will keep that design for now and analyze the performance in future PRs.
  • How should printing be handled? It would be nice for it to print like an n-dimensional array but I don't know of a simple way to make use of AbstractArray printing without reaching into Julia Base internals. One strategy I was trying was to make another type BlockSizesArray which is like BlockSizes but is an AbstractArray subtype, that works ok but then I don't know how to customize printing the type. EDIT: Now it is handled automatically because BlockSizes <: AbstractArray.
  • Should we define blocksizes(a::AbstractArray, d::Integer) = blocklengths(axes(a, d))? That would actually bring back the previous definition of blocksizes(a::AbstractArray, d::Integer). EDIT: Implemented in the latest.

Copy link

codecov bot commented May 8, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.59%. Comparing base (6502fad) to head (e56ca07).
Report is 97 commits behind head on release-1.0.

Additional details and impacted files
@@               Coverage Diff                @@
##           release-1.0     #399       +/-   ##
================================================
+ Coverage         0.00%   95.59%   +95.59%     
================================================
  Files               16       18        +2     
  Lines             1462     1522       +60     
================================================
+ Hits                 0     1455     +1455     
+ Misses            1462       67     -1395     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@mtfishman
Copy link
Collaborator Author

@jishnub @dlfivefifty I think this is ready to review. I listed a few design questions to discuss in the first post.

Seems like the downstream tests pass, I guess they weren't using the previous blocksizes(...) definition.

src/blocks.jl Outdated Show resolved Hide resolved
test/Project.toml Outdated Show resolved Hide resolved
@dlfivefifty
Copy link
Member

Should BlockSizes be a subtype of AbstractArray? In the latest, I didn't go that route and instead implemented the iterator interface. My reasoning was that it is not obvious what eltype should be for arbitrary block arrays, and even within block arrays the types of the sizes of different blocks could be different

Can't we infer the type of the block sizes from the axes? This would fix the printing.

The current design computes the block size of a block using the size of the view of that block. Is that a good definition, or is it better to get the block sizes from the axes?

I suspect using axes is better but this is an optimisation detail that can be changed later.

Should we define blocksizes(a::AbstractArray, d::Integer) = blocklengths(axes(a, d))? That would actually bring back the previous definition of blocksizes(a::AbstractArray, d::Integer).

Sure

@mtfishman
Copy link
Collaborator Author

Thanks for the feedback @dlfivefifty, I will update the PR this week reflecting your suggestions.

@mtfishman mtfishman changed the title [WIP] Redefine blocksizes Redefine blocksizes May 14, 2024
@mtfishman
Copy link
Collaborator Author

@dlfivefifty I believe I've addressed all of your comments and the open issues I listed in the first post.

@dlfivefifty dlfivefifty merged commit ee57d11 into JuliaArrays:release-1.0 May 14, 2024
14 checks passed
dlfivefifty added a commit that referenced this pull request May 17, 2024
* Compact show for `BlockRange` (#248)

* Compact show for BlockRange

* update docstrings

* don't specialize show for zero dim

* fix missing io in print

* missing show tests

* show for BlockIndexRange

* Bump version to v1.0.0-dev

* Add `BlockedOneTo` as the axis type for a `BlockedArray` (#348)

* Add BlockedOneTo

* axes for AbstractBlockedUnitRange returns BlockedOneTo

* Rewrite test using blockedrange instead of BlockedUnitRange

* Update BlockedUnitRange docstring and add for BlockedOneTo/blockedrange

* Show for BlockedOneTo

* Blocklengths for OrdinalRange block sizes

* Update docs

* Return BlockedOneTo in indexing with BlockRange

* Be less fussy in show tests

* Require 1-based lasts in blockedrange

* Disallow offset arrays  in BlockedUnitRange

* undo unnecessary doc change

* Test conversions between BlockedOneTo and BlockedUnitRange

* Reduce the number of convert methods

* Remove axes1 specialization

* Disallow offset block axes and blocks in BlockArray constructor

* Remove unused axes method

* Infinite broadcast tests (#383)

* Specialize blockedrange BroadcastStyle for LazyArrayStyle (#384)

* Specialize blockedrange BroadcastStyle for LazyArrayStyle

* Add compat for LazyArrays

* Define dataids for PseudoBlockArrays (#364) (#385)

* Define dataids for PseudoBlockArrays (#364)

* Don't use dataids of axes

* Banded Matrix extension (#388)

* Move BandedMatrices+BlockArrays code in BlockBandedMatrices to extension

* Bump julia-actions/setup-julia from 1 to 2 (#387)

Bumps [julia-actions/setup-julia](https://github.com/julia-actions/setup-julia) from 1 to 2.
- [Release notes](https://github.com/julia-actions/setup-julia/releases)
- [Commits](julia-actions/setup-julia@v1...v2)

---
updated-dependencies:
- dependency-name: julia-actions/setup-julia
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Move over blockbanded code

* Add tests

* Update Project.toml

* add tests

* Update Project.toml

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Generalize the element type of `BlockedUnitRange` (#337)

* Allow more general BlockUnitRange element types

* Restrict element type

* Get tests passing

* Fix some tests

* Fix some doctests

* Skip broken test in Julia v1.6

* Better support for unitful numbers

* Fix tests

* Stricter types in _BlockedUnitRange

* Improve tests coverage

* Allow non-Int eltypes in BlockedOneTo (#395)

* Allow non-Int eltypes in BlockedOneTo

* Specific constructors in BlockedOneTo

* Restrict eltype to integers in BlockedOneTo constructors

* Tests for construction from a Tuple

* Move LazyArrays extension to LazyArrays.jl (#393)

* Move LazyArrays extension to LazyArrays.jl

* remove LazyArrays

* Move over OneToCumsum

This was type piracy in LazyBandedMatrices.jl

* Update blockaxis.jl

* move out InfiniteArrays.jl tests

* Use FillArrays accumulate overloads (#397)

* Bump julia-actions/setup-julia from 1 to 2 (#387)

Bumps [julia-actions/setup-julia](https://github.com/julia-actions/setup-julia) from 1 to 2.
- [Release notes](https://github.com/julia-actions/setup-julia/releases)
- [Commits](julia-actions/setup-julia@v1...v2)

---
updated-dependencies:
- dependency-name: julia-actions/setup-julia
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Map imported names to correct parentmodules (#391)

* Remove unused imported names (#392)

* Don't import Base.Cartesian (#394)

I don't think this is being used anymore

* Use FillArrays accumulate

* Bump julia-actions/cache from 1 to 2 (#398)

Bumps [julia-actions/cache](https://github.com/julia-actions/cache) from 1 to 2.
- [Release notes](https://github.com/julia-actions/cache/releases)
- [Commits](julia-actions/cache@v1...v2)

---
updated-dependencies:
- dependency-name: julia-actions/cache
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Update Project.toml

* Update Project.toml

* try running Pkg.update()

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Jishnu Bhattacharya <[email protected]>

* Redefine blocksizes (#399)

* Redefine blocksizes

* Revert change to docstring

* Add tests, fix some tests, add docstring

* Fix more tests

* Add test Project.toml

* Git ignore vim temp files

* Fixes to test Project.toml

* Another test Project.toml fix

* Move code, change type design, better code coverage

* Backwards compatibility. Fix doctest.

* Fix tests

* Redesign BlockSizes to be AbstractArray subtype

* Rename PseudoBlockArray to BlockedArray (#401)

* v1.0, add README

* rename files

* Update README.md

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: Jishnu Bhattacharya <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matt Fishman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants